Please document WC_ASN_NO_HEAP at top of asn.c.

Wrap this with WC_ASN_NO_HEAP so its clear this only applies to the NO malloc case.

Consider using WC_BITFIELD or :1 with unsigned to save strut space.

Consider synthesise -> parse. Please document this limitation (also RID) at top of asn.c along with the macro

What does "source must outlive the cert"? Is this comment referring to the source pubKey pointer provided?

🔴 [High] Unused static function build break under WC_ASN_NO_HEAP + WOLFSSL_IP_ALT_NAME/WOLFSSL_RID_ALT_NAME · bug

GenerateDNSEntryIPString (guarded only by #ifdef WOLFSSL_IP_ALT_NAME, line 14284) and GenerateDNSEntryRIDString (#ifdef WOLFSSL_RID_ALT_NAME, line 14355) are static, and their ONLY call sites are lines 14577 and 14583, both of which the PR moved into the new #else (non-WC_ASN_NO_HEAP) branch of SetDNSEntry (the #ifdef WC_ASN_NO_HEAP ... #else ... #endif closes at line 14594). When WC_ASN_NO_HEAP is defined together with WOLFSSL_IP_ALT_NAME or WOLFSSL_RID_ALT_NAME, those callers are compiled out but the function definitions remain, producing defined but not used static functions. Under wolfSSL's common -Werror build jobs this -Wunused-function warning is a hard compile failure. This is not a hypothetical combination: the PR's own WC_ASN_NO_HEAP branch contains explicit #ifdef WOLFSSL_IP_ALT_NAME/#ifdef WOLFSSL_RID_ALT_NAME reject code (asn.c:14521-14531), so the combo is intended to be buildable.

Fix: Gate the two helper definitions with && !defined(WC_ASN_NO_HEAP) (e.g. #if defined(WOLFSSL_IP_ALT_NAME) && !defined(WC_ASN_NO_HEAP) and likewise for GenerateDNSEntryRIDString) so the no-heap + IP/RID-alt-name configuration compiles cleanly under -Werror. Add a CI build combining WC_ASN_NO_HEAP with WOLFSSL_IP_ALT_NAME to catch this.

🟠 [Medium] cert_no_malloc_test uses a cert whose IP SAN the no-heap path fail-closes · test

The positive parse test uses server_cert_der_2048, which (per certs/server-cert.pem) carries X509v3 Subject Alternative Name: DNS:example.com, IP Address:127.0.0.1. Under WC_ASN_NO_HEAP combined with WOLFSSL_IP_ALT_NAME, the new SetDNSEntry rejects ASN_IP_TYPE with ASN_PARSE_E (asn.c:14521-14525), so ParseCert fails and cert_no_malloc_test returns that error, failing the whole wolfCrypt suite. The test therefore silently depends on WOLFSSL_IP_ALT_NAME being undefined, even though the code path it is meant to validate explicitly supports that macro. When -Werror is off this is the runtime symptom of the same combo that otherwise breaks the build.

Fix: Use a DER cert buffer that contains no iPAddress/registeredID SAN for the positive no-heap parse (or explicitly gate the WC_ASN_NO_HEAP assertions when WOLFSSL_IP_ALT_NAME/WOLFSSL_RID_ALT_NAME are defined), and add a separate negative test asserting ASN_PARSE_E for an IP-SAN cert under those macros.

🟠 [Medium] New no-heap key/SAN in-place paths are under-tested · test

cert_no_malloc_test exercises only the pre-existing RSA in-place public-key path plus (at most) a single DNS SAN. The genuinely new code is not covered: StoreKey/StoreEccKey in-place references for Ed25519/Ed448/ECC keys (cert->pubKeyStored == 0), SAN pool nodes whose name pointer must land inside [source, source+maxIdx), the pool-exhaustion MEMORY_E path, and the IP/RID fail-closed path. The RSA-only positive test cannot detect regressions in the Store*Key ECC/Ed branches or in the SAN pool name references.

Fix: Broaden the no-heap test: walk the full cert.altNames chain and confirm every name pointer satisfies source <= name < source+maxIdx and entryStored == 0; add an ECC cert buffer to hit StoreEccKey no-heap; add a synthetic >WC_ASN_MAX_ALTNAMES case expecting MEMORY_E; cover the IP/RID fail-closed path.

🔵 [Low] No-heap SAN name is not NUL-terminated (contract divergence from heap path) · Security

The heap path NUL-terminates dnsEntry->name (dnsEntry_name[strLen] = '\0', line 14572), but the new WC_ASN_NO_HEAP path sets dnsEntry->name = (char*)str pointing directly into the source DER with NO terminator (the following byte is the next ASN.1 element), relying solely on len. Length-based consumers are safe: the core verification path (CheckForAltNames/MatchDomainName in src/internal.c) and the copy paths in src/x509.c use altName->len/dns->len. However, several OpenSSL-compat consumers treat entry->name as a NUL-terminated C string, e.g. X509PrintName (src/x509.c:6956 XSNPRINTF(scratch, MAX_WIDTH, "DNS:%s", entry->name), and the RFC822/URI cases at 6974/6981). Under no-heap those would read past the SAN value into adjacent DER bytes until a stray 0x00, potentially past the end of the cert buffer (out-of-bounds read). Reachability is low because those consumers require OPENSSL_EXTRA/OPENSSL_ALL, which in practice cannot be built under a genuine no-allocator configuration. Flagged because the heap path's NUL-termination is an implicit contract the new path silently breaks.

Fix: Document explicitly (in asn.h near WC_ASN_NO_HEAP and on struct DNS_entry) that under WC_ASN_NO_HEAP name is NOT NUL-terminated and only len is authoritative, mirroring the subjectCN contract. Audit entry->name string consumers (e.g. src/x509.c X509PrintName) to use %.*s with entry->len instead of %s, or compile-guard those print helpers out when WC_ASN_NO_HEAP is defined.

🔵 [Low] altNamePool embedded mid-struct enlarges stack-allocated DecodedCert/DecodedAcert under no-heap · Blast Radius

Under WC_ASN_NO_HEAP an inline DNS_entry altNamePool[WC_ASN_MAX_ALTNAMES] (default 8) plus altNamePoolUsed is embedded directly in both DecodedCert (asn.h:1806-1811) and DecodedAcert (asn.h:3230-3234). These structs are frequently stack-allocated on exactly the embedded/no-heap targets this feature serves, so this adds roughly 8 * sizeof(DNS_entry) bytes (order of a few hundred bytes) to stack usage per parse, which can matter on stack-constrained MCUs. It is the intended zero-allocation trade-off and is behind #ifdef (heap builds unaffected, ABI-safe since the block is fully compiled out in non-no-heap builds). Note the new members are inserted mid-struct (after altNames) rather than appended at the end, contrary to the project's new-members-at-the-end convention; this is only ABI-safe because the whole block is conditional.

Fix: Prefer appending the new members at the end of the struct. Document the added stack cost and that WC_ASN_MAX_ALTNAMES directly scales it, so integrators can size stacks / reduce the pool for constrained targets.

🔵 [Low] New SetDNSEntry call sites exceed the 80-column style limit · style

Several updated SetDNSEntry(cert->heap, WC_DNS_POOL(cert), ...) call sites now exceed the wolfSSL 80-column convention (e.g. asn.c:19066 and 19128), unlike the neighboring wrapped calls. Minor formatting inconsistency introduced by threading the extra pool arguments through the macro.

Fix: Re-wrap the over-length lines to stay within 80 columns, matching the surrounding style.

Please add CI to exercise cert_no_malloc_test.

1. cert_no_malloc_test is unreachable in a real no-malloc build — the exact config it validates. It sits at the end of cert_test(), but cert_test's preamble does XMALLOC(FOURK_BUF,...) at test.c:26060, which returns NULL under WOLFSSL_NO_MALLOC, so cert_test returns early and never reaches it. It's also only called when WOLFSSL_TEST_CERT && !NO_FILESYSTEM, yet the test is deliberately heap/file-free. Recommend: hoist cert_no_malloc_test to run before the heap/filesystem preamble, or invoke it from the main runner independently. That's why I had to exercise the path with a standalone harness instead.
2. CI gap — .github/workflows/no-malloc.yml sets -DWOLFSSL_NO_MALLOC but never -DNO_WOLFSSL_MEMORY, so WC_ASN_NO_HEAP is never compiled in CI. The new path needs both. Recommend adding a config with both macros.